<rss version="2.0" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/">
    <channel>
        <title>Business Analyst Community &amp; Resources | Modern Analyst</title> 
        <link>https://modernanalyst.com</link> 
        <description>RSS feeds for Business Analyst Community &amp; Resources | Modern Analyst</description> 
        <ttl>60</ttl> <item>
    <comments>https://modernanalyst.com/Resources/Articles/tabid/115/ID/7156/Feature-Prioritization-and-Roadmap-Planning-Applying-AI-Agents-for-Optimization.aspx#Comments</comments> 
    <slash:comments>0</slash:comments> 
    <wfw:commentRss>https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&amp;ModuleID=572&amp;ArticleID=7156</wfw:commentRss> 
    <trackback:ping>https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=7156&amp;PortalID=0&amp;TabID=115</trackback:ping> 
    <title>Feature Prioritization and Roadmap Planning : Applying AI Agents for Optimization</title> 
    <link>https://modernanalyst.com/Resources/Articles/tabid/115/ID/7156/Feature-Prioritization-and-Roadmap-Planning-Applying-AI-Agents-for-Optimization.aspx</link> 
    <description>This article examines how the job of planning the roadmap and choosing which features should be prioritized is being changed by AI agents, according to this story. Instead of going with their gut, businesses could make better goods, be less biased, and better meet the needs of both users and companies if they start using data. AI helps teams make better, faster, and more detailed plans early in the planning process.
</description> 
    <dc:creator>adrian</dc:creator> 
    <pubDate>Sun, 01 Mar 2026 22:00:00 GMT</pubDate> 
    <guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:7156</guid> 
    
</item>
<item>
    <comments>https://modernanalyst.com/Resources/Articles/tabid/115/ID/7146/Provenance-UX-How-to-Specify-Why-Should-I-Believe-This-in-Product-Requirements.aspx#Comments</comments> 
    <slash:comments>0</slash:comments> 
    <wfw:commentRss>https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&amp;ModuleID=572&amp;ArticleID=7146</wfw:commentRss> 
    <trackback:ping>https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=7146&amp;PortalID=0&amp;TabID=115</trackback:ping> 
    <title>Provenance UX: How to Specify “Why Should I Believe This?” in Product Requirements</title> 
    <link>https://modernanalyst.com/Resources/Articles/tabid/115/ID/7146/Provenance-UX-How-to-Specify-Why-Should-I-Believe-This-in-Product-Requirements.aspx</link> 
    <description>This article shows business analysts, systems analysts, and product managers how to build &amp;ldquo;trust into the UI&amp;rdquo; by writing practical provenance requirements for AI-enabled features. It introduces a simple Provenance Requirements Template that turns vague goals like &amp;ldquo;show sources&amp;rdquo; into testable product behavior: when to display citations (ideally tied to specific claims), how to handle conflicting sources with a clear tie-breaker, how to define freshness SLAs by claim type and what to do when data is stale, and how to support confidence/uncertainty, &amp;ldquo;what changed,&amp;rdquo; and audit exports. The takeaway is a repeatable way to specify &amp;ldquo;why should I believe this?&amp;rdquo; so answers come with receipts, stay current, and can be verified or audited when needed.
</description> 
    <dc:creator>adrian</dc:creator> 
    <pubDate>Sun, 08 Feb 2026 05:02:00 GMT</pubDate> 
    <guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:7146</guid> 
    
</item>
<item>
    <comments>https://modernanalyst.com/Resources/Articles/tabid/115/ID/7096/Requirements-Friendly-Data-Dictionary-20.aspx#Comments</comments> 
    <slash:comments>0</slash:comments> 
    <wfw:commentRss>https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&amp;ModuleID=572&amp;ArticleID=7096</wfw:commentRss> 
    <trackback:ping>https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=7096&amp;PortalID=0&amp;TabID=115</trackback:ping> 
    <title>Requirements-Friendly Data Dictionary 2.0</title> 
    <link>https://modernanalyst.com/Resources/Articles/tabid/115/ID/7096/Requirements-Friendly-Data-Dictionary-20.aspx</link> 
    <description>This article describes using a Requirements-Friendly Data Dictionary (RFDD) as an alternative to representing a software solution&amp;rsquo;s data-related requirements as User Stories, Use Cases, or traditional Waterfall Requirement statements. Any of these forms can still be used to document the solution&amp;rsquo;s functional requirements. An RFDD spreadsheet-based template or extended requirements management tool (RMT) provides a structured format that supports a business analyst documenting required Record and Field details while eliciting functional requirements.
</description> 
    <dc:creator>adrian</dc:creator> 
    <pubDate>Sun, 30 Nov 2025 20:30:00 GMT</pubDate> 
    <guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:7096</guid> 
    
</item>
<item>
    <comments>https://modernanalyst.com/Resources/Articles/tabid/115/ID/7107/Writing-Non-Functional-Requirements-That-Developers-Actually-Use.aspx#Comments</comments> 
    <slash:comments>0</slash:comments> 
    <wfw:commentRss>https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&amp;ModuleID=572&amp;ArticleID=7107</wfw:commentRss> 
    <trackback:ping>https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=7107&amp;PortalID=0&amp;TabID=115</trackback:ping> 
    <title>Writing Non-Functional Requirements That Developers Actually Use</title> 
    <link>https://modernanalyst.com/Resources/Articles/tabid/115/ID/7107/Writing-Non-Functional-Requirements-That-Developers-Actually-Use.aspx</link> 
    <description>Learn a simple, practical method for turning vague wishes like &amp;ldquo;the system must be fast and secure&amp;rdquo; into concrete, testable non-functional requirements that developers, testers, and ops actually use. This article walks through step-by-step techniques, real-world examples (performance, security, usability, operability), and a quick checklist you can apply to your current projects.
</description> 
    <dc:creator>adrian</dc:creator> 
    <pubDate>Mon, 17 Nov 2025 04:23:00 GMT</pubDate> 
    <guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:7107</guid> 
    
</item>
<item>
    <comments>https://modernanalyst.com/Resources/Articles/tabid/115/ID/7054/Prioritizing-Software-Quality-Requirements.aspx#Comments</comments> 
    <slash:comments>0</slash:comments> 
    <wfw:commentRss>https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&amp;ModuleID=572&amp;ArticleID=7054</wfw:commentRss> 
    <trackback:ping>https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=7054&amp;PortalID=0&amp;TabID=115</trackback:ping> 
    <title>Prioritizing Software Quality Requirements</title> 
    <link>https://modernanalyst.com/Resources/Articles/tabid/115/ID/7054/Prioritizing-Software-Quality-Requirements.aspx</link> 
    <description>You have to determine which quality requirements are most important to your project&amp;rsquo;s success, and then state specific objectives for them so designers can make appropriate choices. This article describes an approach for identifying and specifying the most important quality attributes for your project, adapted from consultant Jim Brosseau&amp;rsquo;s method.
</description> 
    <dc:creator>adrian</dc:creator> 
    <pubDate>Mon, 13 Oct 2025 16:43:00 GMT</pubDate> 
    <guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:7054</guid> 
    
</item>
<item>
    <comments>https://modernanalyst.com/Resources/Articles/tabid/115/ID/6745/Too-Many-Requirements.aspx#Comments</comments> 
    <slash:comments>1</slash:comments> 
    <wfw:commentRss>https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&amp;ModuleID=572&amp;ArticleID=6745</wfw:commentRss> 
    <trackback:ping>https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=6745&amp;PortalID=0&amp;TabID=115</trackback:ping> 
    <title>Too Many Requirements?</title> 
    <link>https://modernanalyst.com/Resources/Articles/tabid/115/ID/6745/Too-Many-Requirements.aspx</link> 
    <description>A reader wrote to me with questions regarding a development project that he thought involved too many requirements and too little flexibility around requirement priorities. (You&amp;rsquo;ve never heard of such a thing before, right?)&amp;nbsp;
</description> 
    <dc:creator>adrian</dc:creator> 
    <pubDate>Tue, 13 May 2025 01:30:00 GMT</pubDate> 
    <guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:6745</guid> 
    
</item>
<item>
    <comments>https://modernanalyst.com/Resources/Articles/tabid/115/ID/6724/The-Pause-that-Refreshes-Asking-the-Right-Question-without-Asking.aspx#Comments</comments> 
    <slash:comments>0</slash:comments> 
    <wfw:commentRss>https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&amp;ModuleID=572&amp;ArticleID=6724</wfw:commentRss> 
    <trackback:ping>https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=6724&amp;PortalID=0&amp;TabID=115</trackback:ping> 
    <title>The Pause that Refreshes: Asking the Right Question without Asking</title> 
    <link>https://modernanalyst.com/Resources/Articles/tabid/115/ID/6724/The-Pause-that-Refreshes-Asking-the-Right-Question-without-Asking.aspx</link> 
    <description>How do you ask the right question?&amp;nbsp; Would it surprise you to know that perhaps the best way of asking the right question is to keep your mouth shut and not ask anything at all?

That previous statement might require some explanation. &amp;nbsp;What I&amp;#39;m talking about here is the pause.&amp;nbsp; It is the space between your response to someone&amp;#39;s question, response&amp;nbsp; or comment and the space before the next question you are asking or comment you are making.
</description> 
    <dc:creator>adrian</dc:creator> 
    <pubDate>Sun, 13 Apr 2025 23:56:00 GMT</pubDate> 
    <guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:6724</guid> 
    
</item>
<item>
    <comments>https://modernanalyst.com/Resources/Articles/tabid/115/ID/6686/How-Much-Scope-Does-a-Project-Need.aspx#Comments</comments> 
    <slash:comments>0</slash:comments> 
    <wfw:commentRss>https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&amp;ModuleID=572&amp;ArticleID=6686</wfw:commentRss> 
    <trackback:ping>https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=6686&amp;PortalID=0&amp;TabID=115</trackback:ping> 
    <title>How Much Scope Does a Project Need? </title> 
    <link>https://modernanalyst.com/Resources/Articles/tabid/115/ID/6686/How-Much-Scope-Does-a-Project-Need.aspx</link> 
    <description>As a business analyst, your role is to act as the compass, steering projects toward their true north. By managing scope, aligning stakeholders, strategizing effectively, mitigating risks, and knowing when to stop, you can ensure that your projects deliver real value without collapsing under the weight of ambition.

The next time you find yourself in a high-pressure project, ask yourself: How much scope does this project truly need? The answer might just be the key to its success.
</description> 
    <dc:creator>adrian</dc:creator> 
    <pubDate>Mon, 17 Feb 2025 20:49:00 GMT</pubDate> 
    <guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:6686</guid> 
    
</item>
<item>
    <comments>https://modernanalyst.com/Resources/Articles/tabid/115/ID/6609/Crafting-Valuable-Requirements-Using-Business-Architecture-and-Artificial-Intelligence.aspx#Comments</comments> 
    <slash:comments>0</slash:comments> 
    <wfw:commentRss>https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&amp;ModuleID=572&amp;ArticleID=6609</wfw:commentRss> 
    <trackback:ping>https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=6609&amp;PortalID=0&amp;TabID=115</trackback:ping> 
    <title>Crafting Valuable Requirements Using Business Architecture and Artificial Intelligence</title> 
    <link>https://modernanalyst.com/Resources/Articles/tabid/115/ID/6609/Crafting-Valuable-Requirements-Using-Business-Architecture-and-Artificial-Intelligence.aspx</link> 
    <description>Planning, managing, and delivering business requirements are daunting undertakings in any organization. It requires a lot of human resources and despite great efforts, the success rate of digital transformation project delivery is usually very low in most organizations, according to Boston Consulting Group and the Harvard Business Review. In this article, we&amp;rsquo;ll touch base on two methodologies that address today&amp;rsquo;s challenges of managing and crafting valuable business requirements, one of which is based on generative artificial intelligence.

Requirement Management in TOGAF Enterprise Architecture

Requirement Management is at the center of enterprise architecture as shown in Figure 1 below. In The Open Group Architecture Framework (TOGAF), a requirement is defined as a statement of need that must be met by the architecture. It typically represents a high-level capability that must be met by the system or enterprise architecture to satisfy a contract, standard, specification, or other formally imposed document. Requirements in TOGAF serve as the basis for planning, defining, designing, and realizing architectural solutions at the business, application, data, and technology levels. They play a crucial role in guiding the development of the architecture to be delivered, ensuring that the final outcome aligns with the strategic goals, stakeholder needs, and operational demands of the organization.
</description> 
    <dc:creator>Transform VA</dc:creator> 
    <pubDate>Sun, 06 Oct 2024 05:03:00 GMT</pubDate> 
    <guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:6609</guid> 
    
</item>
<item>
    <comments>https://modernanalyst.com/Resources/Articles/tabid/115/ID/6602/Requirements-vs-User-Stories-Which-Are-Better.aspx#Comments</comments> 
    <slash:comments>1</slash:comments> 
    <wfw:commentRss>https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&amp;ModuleID=572&amp;ArticleID=6602</wfw:commentRss> 
    <trackback:ping>https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=6602&amp;PortalID=0&amp;TabID=115</trackback:ping> 
    <title>Requirements vs. User Stories: Which Are Better?</title> 
    <link>https://modernanalyst.com/Resources/Articles/tabid/115/ID/6602/Requirements-vs-User-Stories-Which-Are-Better.aspx</link> 
    <description>As someone who has worked as a business analyst for more years than I care to admit, one of the most common questions I get is: &amp;ldquo;Which is better, requirements or user stories?&amp;rdquo; If only the answer were that simple! The truth is, there isn&amp;rsquo;t a clear winner, because they serve different purposes and complement each other in ways that are essential to a successful project.

I&amp;rsquo;ve seen teams try to use only one of the two and miss critical aspects of a project. And I&amp;rsquo;ve seen projects where both were used in tandem, leading to smooth communication, aligned expectations, and a final product that delighted both users and stakeholders. Let me walk you through why both requirements and user stories are important tools in our arsenal as business analysts&amp;mdash;and why, as practitioners, we should never limit ourselves to just one.
</description> 
    <dc:creator>adrian</dc:creator> 
    <pubDate>Mon, 16 Sep 2024 00:29:00 GMT</pubDate> 
    <guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:6602</guid> 
    
</item>
<item>
    <comments>https://modernanalyst.com/Resources/Articles/tabid/115/ID/6541/Priming-A-Powerful-Tool-for-Business-Analysts.aspx#Comments</comments> 
    <slash:comments>0</slash:comments> 
    <wfw:commentRss>https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&amp;ModuleID=572&amp;ArticleID=6541</wfw:commentRss> 
    <trackback:ping>https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=6541&amp;PortalID=0&amp;TabID=115</trackback:ping> 
    <title>Priming: A Powerful Tool for Business Analysts</title> 
    <link>https://modernanalyst.com/Resources/Articles/tabid/115/ID/6541/Priming-A-Powerful-Tool-for-Business-Analysts.aspx</link> 
    <description>Imagine walking into a store and hearing your favorite song playing in the background. Instinctively, you feel more at ease, more inclined to browse, and perhaps even to buy something. This subtle influence on your behavior is no accident&amp;mdash;it is an example of priming at work. Now, picture leveraging this same psychological phenomenon to enhance the effectiveness of business analysis. Welcome to the world of priming, where a well-placed word or image can shape perceptions, drive engagement, and ultimately lead to more successful projects.
</description> 
    <dc:creator>Transform VA</dc:creator> 
    <pubDate>Sun, 04 Aug 2024 04:30:00 GMT</pubDate> 
    <guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:6541</guid> 
    
</item>
<item>
    <comments>https://modernanalyst.com/Resources/Articles/tabid/115/ID/6534/What-Requirements-Are-Needed-When-Implementing-a-COTS-Information-System.aspx#Comments</comments> 
    <slash:comments>0</slash:comments> 
    <wfw:commentRss>https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&amp;ModuleID=572&amp;ArticleID=6534</wfw:commentRss> 
    <trackback:ping>https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=6534&amp;PortalID=0&amp;TabID=115</trackback:ping> 
    <title>What Requirements Are Needed When Implementing a COTS Information System?</title> 
    <link>https://modernanalyst.com/Resources/Articles/tabid/115/ID/6534/What-Requirements-Are-Needed-When-Implementing-a-COTS-Information-System.aspx</link> 
    <description>This article discusses capability-based detailed requirements (DTRs) for a selected Commercial-Off-the-Shelf (COTS) information system. A complete set of DTRs identifies which &amp;ldquo;Out-of-the-Box&amp;rdquo; (OOTB) capabilities are to be implemented as is, which need changing, which aren&amp;rsquo;t needed, and which unsupported capabilities need to be added. A spreadsheet-based template is offered for documenting and managing these requirements.
</description> 
    <dc:creator>Transform VA</dc:creator> 
    <pubDate>Sun, 07 Jul 2024 19:40:00 GMT</pubDate> 
    <guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:6534</guid> 
    
</item>
<item>
    <comments>https://modernanalyst.com/Resources/Articles/tabid/115/ID/6516/What-Requirements-Are-Needed-When-Selecting-a-COTS-Information-System.aspx#Comments</comments> 
    <slash:comments>0</slash:comments> 
    <wfw:commentRss>https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&amp;ModuleID=572&amp;ArticleID=6516</wfw:commentRss> 
    <trackback:ping>https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=6516&amp;PortalID=0&amp;TabID=115</trackback:ping> 
    <title>What Requirements Are Needed When Selecting a COTS Information System?</title> 
    <link>https://modernanalyst.com/Resources/Articles/tabid/115/ID/6516/What-Requirements-Are-Needed-When-Selecting-a-COTS-Information-System.aspx</link> 
    <description>This article discusses the role of Capability-Based High-Level Requirements (HLRs) when an organization has chosen to acquire a Commercial-Off-The-Shelf (COTS) information system. The objective of the system is to contribute to the solution to a business problem or help take advantage of a business opportunity.
</description> 
    <dc:creator>Transform VA</dc:creator> 
    <pubDate>Sun, 09 Jun 2024 05:46:00 GMT</pubDate> 
    <guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:6516</guid> 
    
</item>
<item>
    <comments>https://modernanalyst.com/Resources/Articles/tabid/115/ID/6515/Three-Critical-Mistakes-with-User-Stories.aspx#Comments</comments> 
    <slash:comments>1</slash:comments> 
    <wfw:commentRss>https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&amp;ModuleID=572&amp;ArticleID=6515</wfw:commentRss> 
    <trackback:ping>https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=6515&amp;PortalID=0&amp;TabID=115</trackback:ping> 
    <title>Three Critical Mistakes with User Stories</title> 
    <link>https://modernanalyst.com/Resources/Articles/tabid/115/ID/6515/Three-Critical-Mistakes-with-User-Stories.aspx</link> 
    <description>Navigating agile software development requires awareness of common pitfalls with user stories. Avoiding the mistakes of over-reliance on user stories, treating them as specifications, and not defining user roles clearly can significantly improve your process. By integrating diverse documentation techniques like wireframes, prototypes, and use case specifications alongside user stories, teams can achieve a more holistic and detailed understanding of requirements. This approach fosters collaboration, clarity, and alignment, ultimately leading to more successful software solutions.
</description> 
    <dc:creator>adrian</dc:creator> 
    <pubDate>Mon, 27 May 2024 02:47:00 GMT</pubDate> 
    <guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:6515</guid> 
    
</item>
<item>
    <comments>https://modernanalyst.com/Resources/Articles/tabid/115/ID/6487/Dont-Let-Your-Software-Requirements-Die.aspx#Comments</comments> 
    <slash:comments>0</slash:comments> 
    <wfw:commentRss>https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&amp;ModuleID=572&amp;ArticleID=6487</wfw:commentRss> 
    <trackback:ping>https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=6487&amp;PortalID=0&amp;TabID=115</trackback:ping> 
    <title>Don&#39;t Let Your Software Requirements Die</title> 
    <link>https://modernanalyst.com/Resources/Articles/tabid/115/ID/6487/Dont-Let-Your-Software-Requirements-Die.aspx</link> 
    <description>In the realm of software development, the clarity and accuracy of software requirements are pivotal for project success. Traditionally viewed as static documents to be archived post-project, this perspective neglects their ongoing potential.

Living software requirements is a paradigm where these documents evolve continually with the software, serving as an enduring source of truth. This approach not only maintains relevance but also actively shapes the software&amp;rsquo;s lifecycle, promoting adaptability and precision in development processes.

They ensure that as software grows and changes, the documentation is not left behind, thus avoiding the pitfalls of outdated or irrelevant information - because often zero documentation is worse than out of date documentation!
</description> 
    <dc:creator>Transform VA</dc:creator> 
    <pubDate>Sun, 05 May 2024 22:33:00 GMT</pubDate> 
    <guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:6487</guid> 
    
</item>
<item>
    <comments>https://modernanalyst.com/Resources/Articles/tabid/115/ID/6370/The-Psychology-of-Requirements-Elicitation-Unraveling-the-Human-Factors.aspx#Comments</comments> 
    <slash:comments>1</slash:comments> 
    <wfw:commentRss>https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&amp;ModuleID=572&amp;ArticleID=6370</wfw:commentRss> 
    <trackback:ping>https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=6370&amp;PortalID=0&amp;TabID=115</trackback:ping> 
    <title>The Psychology of Requirements Elicitation: Unraveling the Human Factors</title> 
    <link>https://modernanalyst.com/Resources/Articles/tabid/115/ID/6370/The-Psychology-of-Requirements-Elicitation-Unraveling-the-Human-Factors.aspx</link> 
    <description>Requirement elicitation, a critical part of project development, is often perceived as a purely technical process. However, this is not always the case. Effective requirement elicitation relies not only on technical acumen but also on an understanding of how human cognition, biases, and behaviors shape the process and what we can do to mitigate the negative influence of these inherent human factors. In this article, we selected three critical human factors: confirmation bias, the availability heuristic, and groupthink. These factors are commonly experienced in requirement elicitation activities. The article delves into the intricacies of these human aspects of requirement gathering and illustrates their impact using examples. We dissect the impact of these biases on requirement gathering, shedding light on the potential consequences that can arise when they go unchecked. Furthermore, we discuss strategies and techniques for mitigating these biases, emphasizing the role of requirements analysts as impartial facilitators.
</description> 
    <dc:creator>Transform VA</dc:creator> 
    <pubDate>Sun, 04 Feb 2024 06:08:00 GMT</pubDate> 
    <guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:6370</guid> 
    
</item>
<item>
    <comments>https://modernanalyst.com/Resources/Articles/tabid/115/ID/6368/The-Importance-of-Quality-Requirements-in-Software-Development.aspx#Comments</comments> 
    <slash:comments>0</slash:comments> 
    <wfw:commentRss>https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&amp;ModuleID=572&amp;ArticleID=6368</wfw:commentRss> 
    <trackback:ping>https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=6368&amp;PortalID=0&amp;TabID=115</trackback:ping> 
    <title>The Importance of Quality Requirements in Software Development</title> 
    <link>https://modernanalyst.com/Resources/Articles/tabid/115/ID/6368/The-Importance-of-Quality-Requirements-in-Software-Development.aspx</link> 
    <description>Achieving an equilibrium between the desire to produce more functionality and quality requirements is a challenge in most software development projects. Functional requirements are often in the spotlight because of their tangible impact on user experience and business value. But quality requirements silently underpin a system&amp;rsquo;s reliability, security, and robustness. In this article, we delve into the critical role played by quality requirements and the tension most software projects experience in managing these two types of requirements. Navigating the tension between functionality and quality is a challenge. The allure of visible functionality often overshadows quality attributes, leading to the unintentional neglect of quality requirements. This imbalance can result in costly consequences, including operational disruptions, post-release fixes, and damage to an organization&amp;rsquo;s reputation that may be caused by a security breach or a custom data privacy leak. To address this challenge, organizations must empower their technical teams to influence project priorities and actively participate in shaping product quality.
</description> 
    <dc:creator>Transform VA</dc:creator> 
    <pubDate>Mon, 01 Jan 2024 05:39:00 GMT</pubDate> 
    <guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:6368</guid> 
    
</item>
<item>
    <comments>https://modernanalyst.com/Resources/Articles/tabid/115/ID/6385/Fundamentals-of-Non-Functional-Quality-Requirements-in-1-Easy-Lesson.aspx#Comments</comments> 
    <slash:comments>0</slash:comments> 
    <wfw:commentRss>https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&amp;ModuleID=572&amp;ArticleID=6385</wfw:commentRss> 
    <trackback:ping>https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=6385&amp;PortalID=0&amp;TabID=115</trackback:ping> 
    <title>Fundamentals of Non-Functional (Quality) Requirements in 1 Easy Lesson</title> 
    <link>https://modernanalyst.com/Resources/Articles/tabid/115/ID/6385/Fundamentals-of-Non-Functional-Quality-Requirements-in-1-Easy-Lesson.aspx</link> 
    <description>The objective of this article is to help business analysts deal with the task of eliciting and documenting non-functional requirements (NFRs) - also known as Quality Requirements. It describes NFR fundamentals in terms of who, what, when, where, and why. It&amp;rsquo;s considered one easy lesson because my series on functional requirements needed nine articles, and my series on data fundamentals needed 10.&amp;nbsp;&amp;nbsp;This article assumes that the NFRs are wanted in relation to a software-based solution to a business problem or opportunity. Also assumed is that there are or will be functional requirements for the solution.
</description> 
    <dc:creator>Transform VA</dc:creator> 
    <pubDate>Sun, 10 Dec 2023 08:35:00 GMT</pubDate> 
    <guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:6385</guid> 
    
</item>
<item>
    <comments>https://modernanalyst.com/Resources/Articles/tabid/115/ID/6369/Requirements-in-DevOps-Challenges-and-Exploring-Avenues-for-Integration.aspx#Comments</comments> 
    <slash:comments>0</slash:comments> 
    <wfw:commentRss>https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&amp;ModuleID=572&amp;ArticleID=6369</wfw:commentRss> 
    <trackback:ping>https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=6369&amp;PortalID=0&amp;TabID=115</trackback:ping> 
    <title>Requirements in DevOps: Challenges and Exploring Avenues for Integration</title> 
    <link>https://modernanalyst.com/Resources/Articles/tabid/115/ID/6369/Requirements-in-DevOps-Challenges-and-Exploring-Avenues-for-Integration.aspx</link> 
    <description>DevOps emphasizes rapid development, continuous integration, and automation, which presents a unique challenge in terms of aligning it with the often more structured and linear process of requirements gathering and documentation. This article discuss this tension between two paradigms and how to harmonize them. In this article, we explore the challenges of harmonizing traditional requirements engineering practices with the dynamic nature of DevOps. By embracing open collaboration, continuous feedback, adaptability, and traceability, DevOps teams can navigate these challenges and pave the way for seamless integration. In the context of DevOps, requirements cannot be static artifacts; they become living entities that evolve in tandem with the software. This article is a reflection on the challenges of integrating RE in DevOps and an exploration of avenues to achieve seamless integration.
</description> 
    <dc:creator>Transform VA</dc:creator> 
    <pubDate>Sun, 29 Oct 2023 20:20:00 GMT</pubDate> 
    <guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:6369</guid> 
    
</item>
<item>
    <comments>https://modernanalyst.com/Resources/Articles/tabid/115/ID/6292/Requirements-Communication-in-Virtual-Teams.aspx#Comments</comments> 
    <slash:comments>0</slash:comments> 
    <wfw:commentRss>https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&amp;ModuleID=572&amp;ArticleID=6292</wfw:commentRss> 
    <trackback:ping>https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=6292&amp;PortalID=0&amp;TabID=115</trackback:ping> 
    <title>Requirements Communication in Virtual Teams</title> 
    <link>https://modernanalyst.com/Resources/Articles/tabid/115/ID/6292/Requirements-Communication-in-Virtual-Teams.aspx</link> 
    <description>The COVID-19 pandemic made remote work and virtual teams more popular than ever before. This remote work model seems to be here to stay. According to recent surveys, a high percentage of workers now choose a hybrid work paradigm that involves both remote and in-person work arrangements. It is important to understand its impact on organizations and employees and develop best practices for thriving in this new work paradigm. Successful virtual team collaboration across cultural, organizational, and geographical boundaries requires effective communication that overcomes barriers such as time zone disparities and language barriers. The success of software development projects is dependent on the efficacy of communicating requirements, which can be particularly difficult in virtual teams due to language, culture, and modes of communication. This article aims to examine the prevalent obstacles that arise in requirements communication and suggest potential approaches to improve requirements communication within virtual team settings.
</description> 
    <dc:creator>Transform VA</dc:creator> 
    <pubDate>Sun, 01 Oct 2023 22:03:00 GMT</pubDate> 
    <guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:6292</guid> 
    
</item>
<item>
    <comments>https://modernanalyst.com/Resources/Articles/tabid/115/ID/6268/Natural-Language-Processing-for-Requirements-Engineering.aspx#Comments</comments> 
    <slash:comments>0</slash:comments> 
    <wfw:commentRss>https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&amp;ModuleID=572&amp;ArticleID=6268</wfw:commentRss> 
    <trackback:ping>https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=6268&amp;PortalID=0&amp;TabID=115</trackback:ping> 
    <title>Natural Language Processing for Requirements Engineering</title> 
    <link>https://modernanalyst.com/Resources/Articles/tabid/115/ID/6268/Natural-Language-Processing-for-Requirements-Engineering.aspx</link> 
    <description>Natural Language Processing (NLP) is a branch of artificial intelligence that aims to allow machines to comprehend, interpret, and generate human language. It comprises developing algorithms and models capable of processing natural language input such as text, voice, and pictures in order to do activities traditionally performed by humans. Recent developments in machine learning technology, as well as the availability of large natural language datasets, have allowed NLP to make great strides in recent years. Quality checks, extraction, classification of requirements, requirements modeling, traceability of requirements, and retrieval are the six main areas of focus for NLP tools and studies. In this article, I discuss these advances in NLP for requirements engineering (RE). NLP for requirements engineering is a growing field of study, yet there is a disconnect between research findings and practice. This is because there aren&amp;rsquo;t enough high-quality data sources and domain-specific requirements sources. Despite this, scientific progress has been made in showing potential. The community of practitioners should collaborate with academics and tool suppliers to influence the direction of NPL for RE.
</description> 
    <dc:creator>Transform VA</dc:creator> 
    <pubDate>Sun, 27 Aug 2023 04:59:00 GMT</pubDate> 
    <guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:6268</guid> 
    
</item>
<item>
    <comments>https://modernanalyst.com/Resources/Articles/tabid/115/ID/6288/AI-in-Business-Analysis-Engaging-Stakeholders-with-ChatGPT.aspx#Comments</comments> 
    <slash:comments>0</slash:comments> 
    <wfw:commentRss>https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&amp;ModuleID=572&amp;ArticleID=6288</wfw:commentRss> 
    <trackback:ping>https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=6288&amp;PortalID=0&amp;TabID=115</trackback:ping> 
    <title>AI in Business Analysis:  Engaging Stakeholders with ChatGPT</title> 
    <link>https://modernanalyst.com/Resources/Articles/tabid/115/ID/6288/AI-in-Business-Analysis-Engaging-Stakeholders-with-ChatGPT.aspx</link> 
    <description>What role can generative artificial intelligence, such as ChatGPT, play in business analysis? Could it interview a stakeholder? How would it deal with a difficult stakeholder? It depends on how well it&amp;rsquo;s trained.

I set up a scenario with ChatGPT to conduct an interview with a challenging stakeholder. I prepared it with a prompt to prepare for a difficult stakeholder but did not give it any specific objections. A breakdown of the entire prompt follows the interview scenario and transcript below.
</description> 
    <dc:creator>Transform VA</dc:creator> 
    <pubDate>Sun, 25 Jun 2023 09:57:00 GMT</pubDate> 
    <guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:6288</guid> 
    
</item>
<item>
    <comments>https://modernanalyst.com/Resources/Articles/tabid/115/ID/6260/How-to-Build-a-Grounded-Capability-Model.aspx#Comments</comments> 
    <slash:comments>1</slash:comments> 
    <wfw:commentRss>https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&amp;ModuleID=572&amp;ArticleID=6260</wfw:commentRss> 
    <trackback:ping>https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=6260&amp;PortalID=0&amp;TabID=115</trackback:ping> 
    <title>How to Build a Grounded Capability Model</title> 
    <link>https://modernanalyst.com/Resources/Articles/tabid/115/ID/6260/How-to-Build-a-Grounded-Capability-Model.aspx</link> 
    <description>Business Capabilities are at the heart of an organization&amp;rsquo;s planning ecosystem. Capability mapping serves many purposes, two of which are critical. First, business capabilities are instrumental in setting priorities more quickly focusing on the most profitable initiatives first. Second, well crafted detailed capability-based roadmap allows agile project planning that is more accurate, less risky, and takes less time.
</description> 
    <dc:creator>Transform VA</dc:creator> 
    <pubDate>Sun, 30 Apr 2023 21:25:00 GMT</pubDate> 
    <guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:6260</guid> 
    
</item>
<item>
    <comments>https://modernanalyst.com/Resources/Articles/tabid/115/ID/6254/Requirements-for-Implementing-Packaged-Solutions.aspx#Comments</comments> 
    <slash:comments>0</slash:comments> 
    <wfw:commentRss>https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&amp;ModuleID=572&amp;ArticleID=6254</wfw:commentRss> 
    <trackback:ping>https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=6254&amp;PortalID=0&amp;TabID=115</trackback:ping> 
    <title>Requirements for Implementing Packaged Solutions</title> 
    <link>https://modernanalyst.com/Resources/Articles/tabid/115/ID/6254/Requirements-for-Implementing-Packaged-Solutions.aspx</link> 
    <description>Many organizations acquire and adapt purchased packaged solutions (also called commercial off-the-shelf, or COTS, products) to meet their software needs, instead of building new systems from scratch. Software as a service (SaaS), or cloud, solutions are becoming increasingly available to meet software needs as well. Whether you&amp;rsquo;re using a package as part or all of the solution for a new project or implementing a solution in the cloud, you still need requirements. Requirements let you evaluate solution candidates so that you can select the most appropriate package, and then they let you adapt the package to meet your needs. This article describes several ways to approach requirements definition when you plan to acquire a commercial package to meet your needs.
</description> 
    <dc:creator>adrian</dc:creator> 
    <pubDate>Sun, 09 Apr 2023 23:53:00 GMT</pubDate> 
    <guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:6254</guid> 
    
</item>
<item>
    <comments>https://modernanalyst.com/Resources/Articles/tabid/115/ID/6203/6-More-Important-Requirements-Practices.aspx#Comments</comments> 
    <slash:comments>1</slash:comments> 
    <wfw:commentRss>https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&amp;ModuleID=572&amp;ArticleID=6203</wfw:commentRss> 
    <trackback:ping>https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=6203&amp;PortalID=0&amp;TabID=115</trackback:ping> 
    <title>6 More Important Requirements Practices</title> 
    <link>https://modernanalyst.com/Resources/Articles/tabid/115/ID/6203/6-More-Important-Requirements-Practices.aspx</link> 
    <description>&amp;nbsp;Here are six more practices that, again, virtually every project will find valuable. These are adapted from our book, Software Requirements Essentials: Core Practices for Successful Business Analysis.

Do you have to do them? Of course not&amp;mdash;that&amp;rsquo;s your choice. The requirements police won&amp;rsquo;t hunt you down if you don&amp;rsquo;t. But if you know of any projects that won&amp;rsquo;t find at least five of them valuable, please let us know. We&amp;rsquo;ll notify the Guinness World Records people.
</description> 
    <dc:creator>Transform VA</dc:creator> 
    <pubDate>Sun, 26 Mar 2023 21:11:00 GMT</pubDate> 
    <guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:6203</guid> 
    
</item>
<item>
    <comments>https://modernanalyst.com/Resources/Articles/tabid/115/ID/6074/The-6-Most-Important-Requirements-Practices.aspx#Comments</comments> 
    <slash:comments>0</slash:comments> 
    <wfw:commentRss>https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&amp;ModuleID=572&amp;ArticleID=6074</wfw:commentRss> 
    <trackback:ping>https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=6074&amp;PortalID=0&amp;TabID=115</trackback:ping> 
    <title>The 6 Most Important Requirements Practices</title> 
    <link>https://modernanalyst.com/Resources/Articles/tabid/115/ID/6074/The-6-Most-Important-Requirements-Practices.aspx</link> 
    <description>There are many other valuable requirements activities besides these six. However, these practices greatly increase your chances of building a solution that achieves the desired business outcomes efficiently and effectively. Applying them doesn&amp;rsquo;t guarantee success for any BA, product owner, or product manager. But neglecting them likely ensures failure.
</description> 
    <dc:creator>adrian</dc:creator> 
    <pubDate>Sun, 12 Jun 2022 16:00:00 GMT</pubDate> 
    <guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:6074</guid> 
    
</item>
<item>
    <comments>https://modernanalyst.com/Resources/Articles/tabid/115/ID/6041/Beyond-Good-Requirements-The-Zoom-In-Zoom-Out-Loop.aspx#Comments</comments> 
    <slash:comments>0</slash:comments> 
    <wfw:commentRss>https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&amp;ModuleID=572&amp;ArticleID=6041</wfw:commentRss> 
    <trackback:ping>https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=6041&amp;PortalID=0&amp;TabID=115</trackback:ping> 
    <title>“Beyond Good Requirements- The Zoom In – Zoom Out Loop”</title> 
    <link>https://modernanalyst.com/Resources/Articles/tabid/115/ID/6041/Beyond-Good-Requirements-The-Zoom-In-Zoom-Out-Loop.aspx</link> 
    <description>As an analyst you have to ensure your own understanding of the bigger picture. You have to zoom in and zoom out frequently.&amp;nbsp;You need to analyze either in small initiatives the context under which the ba work will take place. It is possible to get so focused on the solution that your thoughts are stuck only in delivering the solution and forgetting to revisit frequently the alignment with the scope and the context.
</description> 
    <dc:creator>Transform VA</dc:creator> 
    <pubDate>Sun, 17 Apr 2022 16:37:00 GMT</pubDate> 
    <guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:6041</guid> 
    
</item>
<item>
    <comments>https://modernanalyst.com/Resources/Articles/tabid/115/ID/6042/Change-Requests-for-Software-Business-Analysts.aspx#Comments</comments> 
    <slash:comments>0</slash:comments> 
    <wfw:commentRss>https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&amp;ModuleID=572&amp;ArticleID=6042</wfw:commentRss> 
    <trackback:ping>https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=6042&amp;PortalID=0&amp;TabID=115</trackback:ping> 
    <title>Change Requests for Software Business Analysts</title> 
    <link>https://modernanalyst.com/Resources/Articles/tabid/115/ID/6042/Change-Requests-for-Software-Business-Analysts.aspx</link> 
    <description>A change request (CR) is basically any change in the initial set of signed-off requirements. So, typically in a waterfall model implementation, the requirements phase ensures that all the requirements (features/functionalities/functional and non-functional) are agreed upon and documented before development starts. After that, any new scope brought or requested by clients becomes a change request. There is an additional cost associated with implementing a change request.

Even in the agile model of working, although there is flexibility in the implementation of the project, vendors ensure that a high-level set of requirements are discussed and agreed upon. The iterative way of working ensures that clients have their eyes on the product as it is developing and can suggest corrections or alignments. However, no vendor can work with entirely flexible requirements. It&amp;#39;s not feasible from a budgeting standpoint.
</description> 
    <dc:creator>Transform VA</dc:creator> 
    <pubDate>Sun, 27 Mar 2022 22:01:00 GMT</pubDate> 
    <guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:6042</guid> 
    
</item>
<item>
    <comments>https://modernanalyst.com/Resources/Articles/tabid/115/ID/5925/What-Does-It-Take-to-Message-Effectively.aspx#Comments</comments> 
    <slash:comments>0</slash:comments> 
    <wfw:commentRss>https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&amp;ModuleID=572&amp;ArticleID=5925</wfw:commentRss> 
    <trackback:ping>https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=5925&amp;PortalID=0&amp;TabID=115</trackback:ping> 
    <title>What Does It Take to Message Effectively?</title> 
    <link>https://modernanalyst.com/Resources/Articles/tabid/115/ID/5925/What-Does-It-Take-to-Message-Effectively.aspx</link> 
    <description>Is your requirements approach friendly to vocabulary, policies and messages? I mean directly. Wouldn&amp;rsquo;t it be of great help to your organization in achieving its goals if they were? In our experience, policy sources almost always need interpretation and disambiguation to achieve an effective practicable form. As this column discusses, the rule message &amp;lsquo;Reserved for Green Car&amp;rsquo; provides an excellent case in point.
</description> 
    <dc:creator>Transform VA</dc:creator> 
    <pubDate>Mon, 27 Sep 2021 01:40:00 GMT</pubDate> 
    <guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:5925</guid> 
    
</item>
<item>
    <comments>https://modernanalyst.com/Resources/Articles/tabid/115/ID/5907/How-to-Communicate-Persuasively-as-a-Business-Analyst.aspx#Comments</comments> 
    <slash:comments>0</slash:comments> 
    <wfw:commentRss>https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&amp;ModuleID=572&amp;ArticleID=5907</wfw:commentRss> 
    <trackback:ping>https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=5907&amp;PortalID=0&amp;TabID=115</trackback:ping> 
    <title>How to Communicate Persuasively as a Business Analyst</title> 
    <link>https://modernanalyst.com/Resources/Articles/tabid/115/ID/5907/How-to-Communicate-Persuasively-as-a-Business-Analyst.aspx</link> 
    <description>As a business analyst you will have to communicate internally and externally. Many channels and type of communication may be used. Except ensuring that all the parts have understood correctly the message as you have it in your mind, you need also to perceive what you are saying as important, correct and insightful. You need your communication effort to have impact and many times to trigger specific actions.
</description> 
    <dc:creator>adrian</dc:creator> 
    <pubDate>Sun, 29 Aug 2021 22:31:00 GMT</pubDate> 
    <guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:5907</guid> 
    
</item>
<item>
    <comments>https://modernanalyst.com/Resources/Articles/tabid/115/ID/5873/Product-Requirements--Three-Fundamental-Scenarios.aspx#Comments</comments> 
    <slash:comments>0</slash:comments> 
    <wfw:commentRss>https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&amp;ModuleID=572&amp;ArticleID=5873</wfw:commentRss> 
    <trackback:ping>https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=5873&amp;PortalID=0&amp;TabID=115</trackback:ping> 
    <title>Product Requirements - Three Fundamental Scenarios</title> 
    <link>https://modernanalyst.com/Resources/Articles/tabid/115/ID/5873/Product-Requirements--Three-Fundamental-Scenarios.aspx</link> 
    <description>Product configuration requirements are a specialized type of requirement when an information system supports product-related needs through data values. Where there are specific changes to business processes needed to sell and/or operate a new product, the requirements for the information system to support activities within those processes involve standard functional requirements.

Whether an information system can support a product though configuration or requires custom development, when an information system is involved there are standard pre-go-live activities that need to be performed (e.g. testing). Requirements support those activities.
</description> 
    <dc:creator>Transform VA</dc:creator> 
    <pubDate>Sun, 11 Jul 2021 05:23:00 GMT</pubDate> 
    <guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:5873</guid> 
    
</item>
<item>
    <comments>https://modernanalyst.com/Resources/Articles/tabid/115/ID/5793/Overcoming-Common-Business-Analysis-Challenges-Related-to-Glossaries.aspx#Comments</comments> 
    <slash:comments>0</slash:comments> 
    <wfw:commentRss>https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&amp;ModuleID=572&amp;ArticleID=5793</wfw:commentRss> 
    <trackback:ping>https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=5793&amp;PortalID=0&amp;TabID=115</trackback:ping> 
    <title>Overcoming Common Business Analysis Challenges Related to Glossaries</title> 
    <link>https://modernanalyst.com/Resources/Articles/tabid/115/ID/5793/Overcoming-Common-Business-Analysis-Challenges-Related-to-Glossaries.aspx</link> 
    <description>Have you ever imagined a situation wherein your vocabulary is missing all of a sudden? What would happen if words weren&amp;rsquo;t there? Or our vocabulary shrank like &amp;lsquo;Honey I Shrunk the Kids&amp;rsquo;?

Next to silence, words are a very important part of our conversations :-). When it comes to Business Analysis, there are many challenges around definitions. The project Glossary should contain all key business terms. It is such a straight forward thing but we may assume those things. We may put a little less emphasis on creating a rich project Glossary. Let us zoom in a bit into the common challenges of glossaries and also discuss how to overcome them.
</description> 
    <dc:creator>Swatipitre</dc:creator> 
    <pubDate>Sun, 07 Mar 2021 05:01:00 GMT</pubDate> 
    <guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:5793</guid> 
    
</item>
<item>
    <comments>https://modernanalyst.com/Resources/Articles/tabid/115/ID/3151/The-Business-Value-of-Better-Requirements.aspx#Comments</comments> 
    <slash:comments>1</slash:comments> 
    <wfw:commentRss>https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&amp;ModuleID=572&amp;ArticleID=3151</wfw:commentRss> 
    <trackback:ping>https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=3151&amp;PortalID=0&amp;TabID=115</trackback:ping> 
    <title>The Business Value of Better Requirements</title> 
    <link>https://modernanalyst.com/Resources/Articles/tabid/115/ID/3151/The-Business-Value-of-Better-Requirements.aspx</link> 
    <description>&amp;nbsp;Not every manager is convinced that his team needs to do a better job on requirements development and management or that such an investment will pay off. Numerous industry studies, however, indicate that requirements issues are a pervasive cause of project distress. Let&amp;rsquo;s see why investing in better requirements is a smart business decision for any organization.
</description> 
    <dc:creator>Transform VA</dc:creator> 
    <pubDate>Mon, 18 Jan 2021 13:24:00 GMT</pubDate> 
    <guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:3151</guid> 
    
</item>
<item>
    <comments>https://modernanalyst.com/Resources/Articles/tabid/115/ID/5603/Remote-Business-Analysis-Interviewing-and-Facilitating.aspx#Comments</comments> 
    <slash:comments>0</slash:comments> 
    <wfw:commentRss>https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&amp;ModuleID=572&amp;ArticleID=5603</wfw:commentRss> 
    <trackback:ping>https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=5603&amp;PortalID=0&amp;TabID=115</trackback:ping> 
    <title>Remote Business Analysis: Interviewing and Facilitating</title> 
    <link>https://modernanalyst.com/Resources/Articles/tabid/115/ID/5603/Remote-Business-Analysis-Interviewing-and-Facilitating.aspx</link> 
    <description>Business people call remote meetings virtual or on-line sessions, or simply conference calls. For many years we have been utilizing this form of communications to save time and money. Due to the global virus pandemic, remote meetings are now not just convenient, but a necessity for maintaining social distancing. Fortunately we have technology that assists us in managing these remote sessions to not only hear the stakeholders, but see them as well. However, remote stakeholder interviewing and meetings have their additional challenges beyond face-to-face encounters. Regardless of the technology used, we need to be keenly aware of these additional negative risks and pursue mitigations.
</description> 
    <dc:creator>Transform VA</dc:creator> 
    <pubDate>Mon, 07 Sep 2020 05:16:00 GMT</pubDate> 
    <guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:5603</guid> 
    
</item>
<item>
    <comments>https://modernanalyst.com/Resources/Articles/tabid/115/ID/5624/Requirements-Life-Cycle-Management-with-Azure-DevOps.aspx#Comments</comments> 
    <slash:comments>2</slash:comments> 
    <wfw:commentRss>https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&amp;ModuleID=572&amp;ArticleID=5624</wfw:commentRss> 
    <trackback:ping>https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=5624&amp;PortalID=0&amp;TabID=115</trackback:ping> 
    <title>Requirements Life Cycle Management with Azure DevOps</title> 
    <link>https://modernanalyst.com/Resources/Articles/tabid/115/ID/5624/Requirements-Life-Cycle-Management-with-Azure-DevOps.aspx</link> 
    <description>Requirements management is a critical function for business analysis. Requirements management is focused on ensuring that the business users and stakeholders have the following information available...&amp;nbsp;&amp;nbsp;But the more important question to have answer to and where the real business value is delivered in requirements life cycle management is answering the following questions:

    Are the requirements impacting critical business processes?
    Which processes have recurring change?
    Are the requirements priorities aligned to key business processes?
    Which process will be impacted by which requirements?
</description> 
    <dc:creator>Transform VA</dc:creator> 
    <pubDate>Sun, 05 Jul 2020 04:15:00 GMT</pubDate> 
    <guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:5624</guid> 
    
</item>
<item>
    <comments>https://modernanalyst.com/Resources/Articles/tabid/115/ID/5580/Detailed-Requirements-for-Fully-Automating-a-Business-Activity.aspx#Comments</comments> 
    <slash:comments>0</slash:comments> 
    <wfw:commentRss>https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&amp;ModuleID=572&amp;ArticleID=5580</wfw:commentRss> 
    <trackback:ping>https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=5580&amp;PortalID=0&amp;TabID=115</trackback:ping> 
    <title>Detailed Requirements for Fully Automating a Business Activity</title> 
    <link>https://modernanalyst.com/Resources/Articles/tabid/115/ID/5580/Detailed-Requirements-for-Fully-Automating-a-Business-Activity.aspx</link> 
    <description>This final article in the Requirements in Context series discusses detailed requirements for a fully automated business activity. &amp;lsquo;Fully automated&amp;rsquo; means that the business information system (BIS) is expected to perform the activity from start to finish without user involvement. A simple example is the system automatically posting a monthly fee against customer accounts. A more complex example is the system utilizing customer-specific pricing details to determine the amount charged for a purchase made by a customer.
</description> 
    <dc:creator>Transform VA</dc:creator> 
    <pubDate>Tue, 14 Apr 2020 00:08:00 GMT</pubDate> 
    <guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:5580</guid> 
    
</item>
<item>
    <comments>https://modernanalyst.com/Resources/Articles/tabid/115/ID/5564/NFR-Cannot-be-forgotten-technique-often-forgotten.aspx#Comments</comments> 
    <slash:comments>1</slash:comments> 
    <wfw:commentRss>https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&amp;ModuleID=572&amp;ArticleID=5564</wfw:commentRss> 
    <trackback:ping>https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=5564&amp;PortalID=0&amp;TabID=115</trackback:ping> 
    <title>NFR – Cannot be forgotten technique often forgotten</title> 
    <link>https://modernanalyst.com/Resources/Articles/tabid/115/ID/5564/NFR-Cannot-be-forgotten-technique-often-forgotten.aspx</link> 
    <description>&amp;nbsp;
 First of all, any operating system or solution contains two types of requirements: functional and non-functional. The solution works as a clock, which requires each gear within the solution to be properly functioning. Based on the theory of constraints, any process throughput can only be improved when the constraint or bottleneck is resolved.
 Therefore, no matter how fast the train can run and how many passengers it can carry in one trip (the functional requirements), as long as the NFRs are not met, the performance of the solution (subway system) can only be as good as the non-functional requirements.
 Second, if NFRs are not considered during the business analysis process, it is very likely they were not part of the criteria for solution evaluation. Without consideration of NFRs, the proposed solution may not be evaluated accurately. What was thought to be the best solution may not be a suitable solution at all.</description> 
    <dc:creator>Transform VA</dc:creator> 
    <pubDate>Mon, 09 Mar 2020 00:03:00 GMT</pubDate> 
    <guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:5564</guid> 
    
</item>
<item>
    <comments>https://modernanalyst.com/Resources/Articles/tabid/115/ID/5529/Detailed-Requirements-for-Data-Importing-and-Exporting.aspx#Comments</comments> 
    <slash:comments>0</slash:comments> 
    <wfw:commentRss>https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&amp;ModuleID=572&amp;ArticleID=5529</wfw:commentRss> 
    <trackback:ping>https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=5529&amp;PortalID=0&amp;TabID=115</trackback:ping> 
    <title>Detailed Requirements for Data Importing and Exporting</title> 
    <link>https://modernanalyst.com/Resources/Articles/tabid/115/ID/5529/Detailed-Requirements-for-Data-Importing-and-Exporting.aspx</link> 
    <description>It&amp;rsquo;s important for business analysts to recognize that there is a significant amount of non-technical (i.e. business) detail associated with a system interface capability. The interface is either importing data that&amp;rsquo;s needed and available in electronic format from another system, or exporting data in electronic format when it&amp;rsquo;s needed by some other system or organization. The data is either needed in real time or can be processed as a batch job.
</description> 
    <dc:creator>Transform VA</dc:creator> 
    <pubDate>Sun, 09 Feb 2020 21:09:00 GMT</pubDate> 
    <guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:5529</guid> 
    
</item>
<item>
    <comments>https://modernanalyst.com/Resources/Articles/tabid/115/ID/5483/Detailed-Requirements-for-User-Interfaces-and-Reports.aspx#Comments</comments> 
    <slash:comments>0</slash:comments> 
    <wfw:commentRss>https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&amp;ModuleID=572&amp;ArticleID=5483</wfw:commentRss> 
    <trackback:ping>https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=5483&amp;PortalID=0&amp;TabID=115</trackback:ping> 
    <title>Detailed Requirements for User Interfaces and Reports</title> 
    <link>https://modernanalyst.com/Resources/Articles/tabid/115/ID/5483/Detailed-Requirements-for-User-Interfaces-and-Reports.aspx</link> 
    <description>For business analysts working in an environment where there is a gap between SMEs and the delivery of an IT-based solution for business needs, requirements are documented to bridge that gap. You are reading this because you are a business analyst responsible for documenting detailed requirements and, in the case of this article, business needs involving one or more user interfaces (UIs) or reports.

The objective of this article is to answer the question, &amp;ldquo;How much detail is necessary?&amp;rdquo; Spoiler alert &amp;ndash; quite a bit. This is to avoid, as much as possible, a BA having to go back to a SME when designers or developers have business-level questions about a UI or report. Or worse &amp;ndash; designers or developers&amp;nbsp;not&amp;nbsp;asking questions. Instead, making assumptions about what the business needs and proceeding to deliver the solution based on those assumptions.
</description> 
    <dc:creator>Transform VA</dc:creator> 
    <pubDate>Sun, 01 Dec 2019 23:14:00 GMT</pubDate> 
    <guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:5483</guid> 
    
</item>
<item>
    <comments>https://modernanalyst.com/Resources/Articles/tabid/115/ID/5471/The-Problems-Addressed-by-Business-Rules.aspx#Comments</comments> 
    <slash:comments>0</slash:comments> 
    <wfw:commentRss>https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&amp;ModuleID=572&amp;ArticleID=5471</wfw:commentRss> 
    <trackback:ping>https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=5471&amp;PortalID=0&amp;TabID=115</trackback:ping> 
    <title>The Problems Addressed by Business Rules</title> 
    <link>https://modernanalyst.com/Resources/Articles/tabid/115/ID/5471/The-Problems-Addressed-by-Business-Rules.aspx</link> 
    <description>Business rules cover a very broad space. Across the entire space, however, you can be sure about one central idea &amp;ndash; business logic should not be buried in procedural programming languages. Call it rule independence.&amp;nbsp;&amp;nbsp;Why is rule independence important to you? Because rules entangled in procedural code won&amp;rsquo;t ever be agile. Rules change all the time &amp;ndash; and in a digital world the pace of change is always accelerating. How you can stay on top of it is the central question in business agility.
</description> 
    <dc:creator>Transform VA</dc:creator> 
    <pubDate>Sun, 24 Nov 2019 06:46:00 GMT</pubDate> 
    <guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:5471</guid> 
    
</item>
<item>
    <comments>https://modernanalyst.com/Resources/Articles/tabid/115/ID/5464/9-Types-Of-Requirements-Documents-What-They-Mean-And-Who-Writes-Them.aspx#Comments</comments> 
    <slash:comments>0</slash:comments> 
    <wfw:commentRss>https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&amp;ModuleID=572&amp;ArticleID=5464</wfw:commentRss> 
    <trackback:ping>https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=5464&amp;PortalID=0&amp;TabID=115</trackback:ping> 
    <title>9 Types Of Requirements Documents: What They Mean And Who Writes Them</title> 
    <link>https://modernanalyst.com/Resources/Articles/tabid/115/ID/5464/9-Types-Of-Requirements-Documents-What-They-Mean-And-Who-Writes-Them.aspx</link> 
    <description>Requirements documents are used to communicate the aims of a project in a clear, concise way to ensure all stakeholders are on the same page.&amp;nbsp; When we talk about a requirements document we are often referring to a Business Requirements Document - or a BRD.&amp;nbsp; But as well as a BRD, there are 9 other types of requirements documents that a business may want to use while pushing a project through its stages of completion. The type of format to be used depends on the result of the project itself, whether it&amp;rsquo;s a product, service or system, and the particular requirements it has.
</description> 
    <dc:creator>Transform VA</dc:creator> 
    <pubDate>Tue, 22 Oct 2019 06:28:00 GMT</pubDate> 
    <guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:5464</guid> 
    
</item>
<item>
    <comments>https://modernanalyst.com/Resources/Articles/tabid/115/ID/5360/Requirements-Review-Challenges.aspx#Comments</comments> 
    <slash:comments>0</slash:comments> 
    <wfw:commentRss>https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&amp;ModuleID=572&amp;ArticleID=5360</wfw:commentRss> 
    <trackback:ping>https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=5360&amp;PortalID=0&amp;TabID=115</trackback:ping> 
    <title>Requirements Review Challenges</title> 
    <link>https://modernanalyst.com/Resources/Articles/tabid/115/ID/5360/Requirements-Review-Challenges.aspx</link> 
    <description>If someone said you could only perform a single quality practice on a software project, what would you choose? I&amp;rsquo;d pick peer reviews of requirements, which I believe are the highest-leverage quality practice we have available today.&amp;nbsp;&amp;nbsp;In a peer review, someone other than the author of a work product examines the product for quality problems and improvement opportunities. Reviewing requirements is a powerful technique. Use them to identify ambiguous or unverifiable requirements, find requirements that aren&amp;rsquo;t sufficiently detailed yet, spot conflicts between requirements, and reveal numerous other problems.</description> 
    <dc:creator>Transform VA</dc:creator> 
    <pubDate>Mon, 05 Aug 2019 01:42:00 GMT</pubDate> 
    <guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:5360</guid> 
    
</item>
<item>
    <comments>https://modernanalyst.com/Resources/Articles/tabid/115/ID/5356/Making-Requirements-Reusable.aspx#Comments</comments> 
    <slash:comments>0</slash:comments> 
    <wfw:commentRss>https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&amp;ModuleID=572&amp;ArticleID=5356</wfw:commentRss> 
    <trackback:ping>https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=5356&amp;PortalID=0&amp;TabID=115</trackback:ping> 
    <title>Making Requirements Reusable</title> 
    <link>https://modernanalyst.com/Resources/Articles/tabid/115/ID/5356/Making-Requirements-Reusable.aspx</link> 
    <description>Reuse is an eternal grail for those who seek increased software productivity. Reusing requirements can increase productivity, improve quality, and lead to greater consistency between related systems.
Reuse is not free, though. It presents its own risks, both with regard to reusing existing items and to creating items with good reuse potential. It might take more effort to create high-quality reusable requirements than to write requirements you intend to use only on the current project. In this article&amp;nbsp;we describe some approaches an organization could take to maximize the reuse potential of its requirements.</description> 
    <dc:creator>Transform VA</dc:creator> 
    <pubDate>Sun, 07 Jul 2019 12:20:00 GMT</pubDate> 
    <guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:5356</guid> 
    
</item>
<item>
    <comments>https://modernanalyst.com/Resources/Articles/tabid/115/ID/5384/Keeping-High-Level-Requirements-High-Level.aspx#Comments</comments> 
    <slash:comments>0</slash:comments> 
    <wfw:commentRss>https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&amp;ModuleID=572&amp;ArticleID=5384</wfw:commentRss> 
    <trackback:ping>https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=5384&amp;PortalID=0&amp;TabID=115</trackback:ping> 
    <title>Keeping High-Level Requirements High-Level</title> 
    <link>https://modernanalyst.com/Resources/Articles/tabid/115/ID/5384/Keeping-High-Level-Requirements-High-Level.aspx</link> 
    <description>The objective of this article is to provide business analysts with guidelines for distinguishing between high-level requirements (HLRs) and detail requirements (in&amp;nbsp;IIBA&amp;reg; BABOK&amp;reg;&amp;nbsp;V3 terms &amp;ndash; Stakeholder requirements and Solution requirements respectively).
</description> 
    <dc:creator>adrian</dc:creator> 
    <pubDate>Sun, 30 Jun 2019 23:33:00 GMT</pubDate> 
    <guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:5384</guid> 
    
</item>
<item>
    <comments>https://modernanalyst.com/Resources/Articles/tabid/115/ID/5271/How-To-Build-Right-Product-Backlog-Structure.aspx#Comments</comments> 
    <slash:comments>0</slash:comments> 
    <wfw:commentRss>https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&amp;ModuleID=572&amp;ArticleID=5271</wfw:commentRss> 
    <trackback:ping>https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=5271&amp;PortalID=0&amp;TabID=115</trackback:ping> 
    <title>How To Build Right Product Backlog Structure</title> 
    <link>https://modernanalyst.com/Resources/Articles/tabid/115/ID/5271/How-To-Build-Right-Product-Backlog-Structure.aspx</link> 
    <description>	In this article, I want to share my knowledge on how to manage product backlog using Jira. The article will be useful not only to business analysts or product owners but also to scrum masters, project managers. Basically, anyone who works with backlog and requirements on a project will benefit from reading it. There are certain rules and approaches that you have to follow to achieve good results.
	Before we take a look at it I want to point out that this approach is not a market standard yet. However, over the last 3 years, I&amp;rsquo;ve completed a good number of projects using the approach I&amp;rsquo;ll be describing here
	On the image below I tried to emphasize the main activities and processes that should be presented in your project. You also have to keep in mind that each artifact and process has own goal and definition.</description> 
    <dc:creator>Transform VA</dc:creator> 
    <pubDate>Sun, 03 Mar 2019 20:52:00 GMT</pubDate> 
    <guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:5271</guid> 
    
</item>
<item>
    <comments>https://modernanalyst.com/Resources/Articles/tabid/115/ID/5144/Managing-Requirements-is-an-Art-Mastered-by-a-Business-Analyst.aspx#Comments</comments> 
    <slash:comments>0</slash:comments> 
    <wfw:commentRss>https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&amp;ModuleID=572&amp;ArticleID=5144</wfw:commentRss> 
    <trackback:ping>https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=5144&amp;PortalID=0&amp;TabID=115</trackback:ping> 
    <title>Managing Requirements is an Art Mastered by a Business Analyst</title> 
    <link>https://modernanalyst.com/Resources/Articles/tabid/115/ID/5144/Managing-Requirements-is-an-Art-Mastered-by-a-Business-Analyst.aspx</link> 
    <description>In a classic business analyst universe, requirements are the soul of all the work a business analyst does. If a business analyst fails to identify and translate the right requirements, they&amp;rsquo;re out of a job. This is the reason why a successful business analyst is always good at requirements handling/management process.
What makes requirements an essential part of a BA&amp;rsquo;s job?
For a business analyst, requirements are defined as the logical and essential steps which needs to be fulfilled in order to achieve a successful end-state or a solution to a stakeholder&amp;rsquo;s business problem. These requirements drive the solution and are the key elements of any successful solution implementation. Business analysts are the ones who not only ensures the expected solution is delivered, but they&amp;rsquo;re also the owner of the requirements handling/management process. Business analysts identify the right requirements and help them convert into a form consumable by delivery teams to deliver the expected outcome in a timely manner. 
The requirements management/handling process consists of 4 basic steps: Discovery, Analyze, Draft and Implement.
1.&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; Discovery
Requirements discovery is a phase in which we identify, gather and scope the requirements. This phase builds the basic requirements framework for delivery. To identify and gather requirements, a business analyst uses various requirements elicitation techniques like observation, shadowing, protocol analysis, apprenticeship, prototyping, focus groups, scenario&amp;rsquo;s, background research and many others. These techniques are aimed towards gathering information related to a business problem and/or a solution that business stakeholders are trying to achieve.
Requirements identification is a highly interactive activity, which relies on the involvement of the right stakeholders. Elicitation activities continue while a business analyst traverse through other stages/steps of requirements gathering.
It is very important for a business analyst to not only identify but to scope the requirement. Requirements are driven by information collected by various elicitation methods; however, the relevancy of the requirement needs to be determined.
The simplest way to do so is to perform some of the elicitation techniques repetitively. Look for facts via secondary support of documents or information from another source just to verify. Chart your scope based on the overall direction of the information flow and the end-state which stakeholders are trying to achieve. 
Scoping cannot be definitive in the business analyst&amp;rsquo;s landscape. It&amp;rsquo;s a loose boundary which needs to be flexible enough to account for other business or priority changes. Loose boundaries do help the business analyst in defining a playground where they need to operate for a successful outcome.
2.&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; Analyze
The most important activity of the requirements handling process is to analyze a requirement. Analyzing a requirement will provide us with a definite outcome along with the complete information on achieving that outcome. There can be various types of analysis like strategic analysis, functional and technical analysis. 
Strategic analysis is performed by understanding the strengths, weakness, opportunities and threats provided by implementing this requirement. It helps a business analyst to understand the priority and criticality of the requirement which also determines how essential it is for a business to implement those requirements.
Functional analysis provides an ability to understand the requirement from the end user perspective.&amp;nbsp; It is performed by interacting with people who&amp;rsquo;re impacted by the implementation of requirements. This provides unique opportunity for a business analyst to shape the solution in a way that accommodates the minimal, easy to adapt change to the end users or the impacted.
Technical analysis is performed by further breaking down functional requirements into a series of small implementation steps which a delivery person can understand. It is the delivery person/team who needs to deliver the technical solution. It is important to not miss any aspect of functional requirement to be translated into technical requirements which is a supporting pillar for successful solution implementation.
Depending upon the type of analysis, we determine the type of requirement. Upon successfully analyzing and understanding the type of requirement we start drafting requirements into various artifacts.
3.&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; Draft
Once a business analyst has understood the type of requirements and its expected outcome, business analyst can draft those requirements in their respective artifacts. There&amp;rsquo;re various artifacts such as business requirements document and/or specification requirements document and user stories which are authored and owned by a business analyst while there&amp;rsquo;re some other like project charter, technical design document or anything alike to which a business analyst contributes actively. Drafting of requirements take the utmost time as the translation needs clarifications and numerous back and forth interactions. Once a requirement drafting is complete, it&amp;rsquo;s time to walk them through with the entire team.
4.&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; Implement
The first step of requirements implementation is to arrange for a walk-through of freshly drafted requirements where the audience includes all stakeholders including delivery team. This walk-through session helps with course correction of requirements if there&amp;rsquo;s a miss while drafting them. Also, requirements walkthrough is a common platform where in the stakeholders and other team members have the opportunity to ensure alignment of the requirements to the desired end state. Once the requirements are defined and finalized, business analysts have to ensure continuous requirement refinement for successful delivery.
This is the final step of requirements management process. Once the requirement has been identified, scoped, analyzed, drafted and confirmed, business analysts have to keep their eye out for on-going business changes, these changes may affect any of the existing requirements and their desired outcomes. As business changes are constant, the impacts on the already drafted requirements is constant. There is a small deviation of requirements which can still be managed by refining the requirement and updating them, but then if the deviation requires additional effort for which the cost involved is high, then changes are to be considered for enhancement. This decision must be evaluated by a business analyst before taking appropriate actions accordingly.
At this stage, all the requirements are the guiding principle for the delivery team to deliver the solution. Requirements Handling/Management Process is the one, a business analyst has to master to be considered as successful.



Author: Nimil Parikh, Business Analyst


Nimil Parikh is a new generation business analyst who transforms business processes by leveraging IT tools and applications. He has over 7 years of experience modeling, analyzing, measuring, improving, optimizing and automating business processes. He adds value by his ability to context switch while providing cross-functional business solution and ensuring timely delivery by managing and streamlining business processes and driving strategic leadership. He is known to introduce IT business transformation and ensure successful implementation. Nimil possess MBA from San Jose State university, MBA Marketing and Information technology engineering from India. Nimil lives in Campbell, California. He enjoys challenges and believes in making things right. Reach him via email &amp;ndash; parikhnimil@yahoo.co.in
&amp;nbsp;

</description> 
    <dc:creator>Nimil Parikh</dc:creator> 
    <pubDate>Sun, 21 Oct 2018 21:22:00 GMT</pubDate> 
    <guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:5144</guid> 
    
</item>
<item>
    <comments>https://modernanalyst.com/Resources/Articles/tabid/115/ID/4968/Non-Functional-Requirements-Scalability.aspx#Comments</comments> 
    <slash:comments>2</slash:comments> 
    <wfw:commentRss>https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&amp;ModuleID=572&amp;ArticleID=4968</wfw:commentRss> 
    <trackback:ping>https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=4968&amp;PortalID=0&amp;TabID=115</trackback:ping> 
    <title>Non-Functional Requirements: Scalability</title> 
    <link>https://modernanalyst.com/Resources/Articles/tabid/115/ID/4968/Non-Functional-Requirements-Scalability.aspx</link> 
    <description>
Non-functional Requirements capture conditions that do not directly relate to the behaviour or functionality of the solution, but rather describe environmental conditions under which the solution must remain effective or qualities that the systems must have. They are also known as quality or supplementary requirements. These can include requirements related to capacity, speed, security, availability and the information architecture and presentation of the user interface.

</description> 
    <dc:creator>Transform VA</dc:creator> 
    <pubDate>Sat, 23 Jun 2018 04:01:00 GMT</pubDate> 
    <guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:4968</guid> 
    
</item>
<item>
    <comments>https://modernanalyst.com/Resources/Articles/tabid/115/ID/4923/Intelligent-Business-Requirements.aspx#Comments</comments> 
    <slash:comments>0</slash:comments> 
    <wfw:commentRss>https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&amp;ModuleID=572&amp;ArticleID=4923</wfw:commentRss> 
    <trackback:ping>https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=4923&amp;PortalID=0&amp;TabID=115</trackback:ping> 
    <title>Intelligent Business Requirements</title> 
    <link>https://modernanalyst.com/Resources/Articles/tabid/115/ID/4923/Intelligent-Business-Requirements.aspx</link> 
    <description>Intelligent Business Requirements are business needs and objectives that were designed to add business value and promote scalability and innovation.
&amp;lsquo;Project success&amp;rsquo; is the attainment of predefined criteria that emerge from attainment of user requirements. User requirements, in turn, are defined by an evaluation of the business and functional requirements. Thus requirements pave the path that leads to project success.</description> 
    <dc:creator>Transform VA</dc:creator> 
    <pubDate>Mon, 22 Jan 2018 00:32:00 GMT</pubDate> 
    <guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:4923</guid> 
    
</item>
<item>
    <comments>https://modernanalyst.com/Resources/Articles/tabid/115/ID/3149/Requirements-for-Devices-Around-Us-Embedded-Systems-Part-2.aspx#Comments</comments> 
    <slash:comments>0</slash:comments> 
    <wfw:commentRss>https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&amp;ModuleID=572&amp;ArticleID=3149</wfw:commentRss> 
    <trackback:ping>https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=3149&amp;PortalID=0&amp;TabID=115</trackback:ping> 
    <title>Requirements for Devices Around Us: Embedded Systems, Part 2</title> 
    <link>https://modernanalyst.com/Resources/Articles/tabid/115/ID/3149/Requirements-for-Devices-Around-Us-Embedded-Systems-Part-2.aspx</link> 
    <description>&amp;nbsp;In this article we look at some quality attributes that are particularly vital to explore when specifying requirements for embedded systems projects. Quality attributes for embedded systems can be much more complex and intertwined than those for other applications. Business software is generally used in an office where there&amp;rsquo;s not much variance in the environment. In contrast, the operating environment for embedded systems could involve temperature extremes, vibration, shock, and other factors that dictate specific quality considerations.</description> 
    <dc:creator>Transform VA</dc:creator> 
    <pubDate>Mon, 23 Oct 2017 00:43:00 GMT</pubDate> 
    <guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:3149</guid> 
    <enclosure url="https://modernanalyst.com:443/Portals/0/Public%20Uploads%205/1_Embedded-Systems-Requirements-Fotolia_80228567_XS.jpg" length="18953" type="image/jpeg" />
</item>
<item>
    <comments>https://modernanalyst.com/Resources/Articles/tabid/115/ID/3770/Documenting-Requirements-for-Outsourced-Projects.aspx#Comments</comments> 
    <slash:comments>0</slash:comments> 
    <wfw:commentRss>https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&amp;ModuleID=572&amp;ArticleID=3770</wfw:commentRss> 
    <trackback:ping>https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=3770&amp;PortalID=0&amp;TabID=115</trackback:ping> 
    <title>Documenting Requirements for Outsourced Projects</title> 
    <link>https://modernanalyst.com/Resources/Articles/tabid/115/ID/3770/Documenting-Requirements-for-Outsourced-Projects.aspx</link> 
    <description>The purpose of this brief article is to explain the connection between documenting requirements and contract type. Recently I consulted with a firm eliciting requirements for a new product. In this case, an internal business analyst team was documenting the product requirements by consulting with appropriate stakeholders. The follow-on project intent was to outsource the work to develop the product in the form of a contract.
</description> 
    <dc:creator>Transform VA</dc:creator> 
    <pubDate>Sun, 11 Jun 2017 13:30:00 GMT</pubDate> 
    <guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:3770</guid> 
    
</item>

    </channel>
</rss>